Application resource usage information

ABSTRACT

An environment is described in which a processing system provides application-level usage information to users. In one scenario, for example, the processing system may provide personal usage information to a user who is operating a user device. The personal usage information itemizes the amount of data (and/or other resources) that has been consumed by each application run by the user device. In another scenario, the processing system may provide expected usage information associated with at least one candidate application provided by a marketplace system. The expected usage information describes an expected consumption of data (and/or other resources) by the candidate application upon running the candidate application by the user device. The processing system can tailor the expected usage information that it sends to a particular user based on user profile data. The user profile data describes a manner in which users operate applications.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a Continuation of U.S. patent application Ser. No.15/627,298, filed Jun. 19, 2017, and entitled “Application ResourceUsage Information”, which is a Continuation of U.S. patent applicationSer. No. 13/293,149, now U.S. Pat. No. 8,880,022, filed on Nov. 10,2011, and entitled “Providing Per-Application Resource UsageInformation.” In addition, this application is a Continuation of U.S.patent application Ser. No. 14/517,835, now U.S. Pat. No. 9,247,017,filed on Oct. 18, 2014, and entitled “Providing Per-Application ResourceUsage Information.” In addition, this application is a Continuation ofU.S. patent application Ser. No. 15/005,283, now U.S. Pat. No.9,686,419, filed on Jan. 25, 2016, and entitled “INTERACTIVE APPLICATIONRESOURCE USAGE INFORMATION”, the entire contents of each of which arehereby incorporated herein by reference for all purposes.

BACKGROUND

User devices may communicate with remote entities via wirelesscommunication, subject to different types of contractual data plans. Ina first type of data plan, a wireless communication provider (a“provider”) may allow a user to consume an unlimited amount of datawithin a billing cycle without the payment of usage-related surcharges.As used herein, an application is said to “consume” data when it causesthe data to be sent or received over wireless communicationinfrastructure. In a second type of data plan, a provider may allow auser to consume data up to an identified threshold in the course of thebilling cycle, or to consume data on a per-transaction basis.

In environments that use the second type of data plan, a provider canoffer various tools that enable a user to determine the total amount ofdata that he or she has consumed at any point in the billing cycle. Forexample, in one case, the user may send a usage-related inquiry to aserver associated with the provider. The server responds by notifyingthe user of the total amount of data that has been consumed by theuser's device thus far in the billing cycle.

The above-described tool helps the user regulate his or her consumptionof data. However, there is room for improvement in known systems forconveying usage-related information to users.

SUMMARY

An environment is described herein in which a processing system providesapplication-level usage information to users. In one scenario, forexample, the processing system may provide personal usage information toa user who is operating a user device. The personal usage informationitemizes the amount of data (and/or other resource(s)) that have beenconsumed by each application that is run by the user device within adefined period of time. The processing system can generate the personalusage information by collecting actual usage data from the user device.

In another scenario, the processing system may provide expected usageinformation associated with at least one candidate application providedby a marketplace system. The expected usage information describes anamount of data (and/or other resource(s)) that the candidate applicationis expected to consume after it is run by the user device. Theprocessing system can generate the expected usage information bycollecting actual usage data from a group of user devices which havepreviously executed the candidate application, and then processing thatactual usage data in various ways (e.g., by forming an average value,etc.). Alternatively, or in addition, the processing system can generatethe expected usage information based on simulated usage data.

According to another illustrative feature, the processing system cantailor the expected usage information that it sends to a particular userbased on user profile data. In one case, the user profile datacharacterizes the consumption-related behavior of the particular user,as well as each user in a group of other users. More specifically, theprocessing system can leverage the user profile data to generateexpected usage information based on actual usage data received from asubset of the other users who share at least one usage-relatedcharacteristic in common with the particular user.

The above approach can be manifested in various types of systems,components, methods, computer readable media, data structures, articlesof manufacture, and so on.

This Summary is provided to introduce a selection of concepts in asimplified form; these concepts are further described below in theDetailed Description. This Summary is not intended to identify keyfeatures or essential features of the claimed subject matter, nor is itintended to be used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an illustrative environment in which a processing systemsends application-level usage information to a user device, based onactual usage data forwarded to the processing system by the user device.

FIG. 2 shows one illustrative implementation of the environment of FIG.1.

FIG. 3 shows one illustrative implementation of a reporting module thatmay be used in the environment of FIG. 1.

FIG. 4 shows one illustrative implementation of a usage analysis modulethat may be used in the environment of FIG. 1.

FIG. 5 shows one illustrative implementation of a marketplace systemthat may be used in the environment of FIG. 1.

FIG. 6 shows one illustrative implementation of a usage managementmodule that may be used in the environment of FIG. 1.

FIG. 7 shows one illustrative implementation of analysis logic and usagepresentation logic that may be used in the environment of FIG. 1.

FIGS. 8-15 show examples of different types of usage information thatthe environment of FIG. 1 can provide to a user or other entity.

FIG. 16 is a flowchart that describes one illustrative manner ofoperation of the environment of FIG. 1.

FIG. 17 is a flowchart that describes one illustrative manner ofoperation of the reporting module of FIG. 3.

FIG. 18 is a flowchart that describes one illustrative manner ofoperation of a device modification module shown in FIG. 6; the devicemodification module operates by modifying an application installed on auser device (or otherwise accessible to the user device) based on anamount of data (or other resource(s)) consumed by the application.

FIG. 19 is a flowchart that describes one illustrative manner ofproviding expected usage information based, in part, on user profiledata.

FIG. 20 shows illustrative computing functionality that can be used toimplement any aspect of the features shown in the foregoing drawings.

The same numbers are used throughout the disclosure and figures toreference like components and features. Series 100 numbers refer tofeatures originally found in FIG. 1, series 200 numbers refer tofeatures originally found in FIG. 2, series 300 numbers refer tofeatures originally found in FIG. 3, and so on.

DETAILED DESCRIPTION

This disclosure is organized as follows. Section A describes anillustrative environment for supplying application-level usageinformation to users who operate applications on respective userdevices. Section B describes illustrative methods which explain theoperation of the environment of Section A. Section C describesillustrative computing functionality that can be used to implement anyaspect of the features described in Sections A and B.

As a preliminary matter, some of the figures describe concepts in thecontext of one or more structural components, variously referred to asfunctionality, modules, features, elements, etc. The various componentsshown in the figures can be implemented in any manner by any physicaland tangible mechanisms, for instance, by software, hardware (e.g.,chip-implemented logic functionality), firmware, etc., and/or anycombination thereof. In one case, the illustrated separation of variouscomponents in the figures into distinct units may reflect the use ofcorresponding distinct physical and tangible components in an actualimplementation. Alternatively, or in addition, any single componentillustrated in the figures may be implemented by plural actual physicalcomponents. Alternatively, or in addition, the depiction of any two ormore separate components in the figures may reflect different functionsperformed by a single actual physical component. FIG. 20, to bediscussed in turn, provides additional details regarding oneillustrative physical implementation of the functions shown in thefigures.

Other figures describe the concepts in flowchart form. In this form,certain operations are described as constituting distinct blocksperformed in a certain order. Such implementations are illustrative andnon-limiting. Certain blocks described herein can be grouped togetherand performed in a single operation, certain blocks can be broken apartinto plural component blocks, and certain blocks can be performed in anorder that differs from that which is illustrated herein (including aparallel manner of performing the blocks). The blocks shown in theflowcharts can be implemented in any manner by any physical and tangiblemechanisms, for instance, by software, hardware (e.g., chip-implementedlogic functionality), firmware, etc., and/or any combination thereof.

As to terminology, the phrase “configured to” encompasses any way thatany kind of physical and tangible functionality can be constructed toperform an identified operation. The functionality can be configured toperform an operation using, for instance, software, hardware (e.g.,chip-implemented logic functionality), firmware, etc., and/or anycombination thereof.

The term “logic” encompasses any physical and tangible functionality forperforming a task. For instance, each operation illustrated in theflowcharts corresponds to a logic component for performing thatoperation. An operation can be performed using, for instance, software,hardware (e.g., chip-implemented logic functionality), firmware, etc.,and/or any combination thereof. When implemented by a computing system,a logic component represents an electrical component that is a physicalpart of the computing system, however implemented.

The phrase “means for” in the claims, if used, is intended to invoke theprovisions of 35 U.S.C. § 112, sixth paragraph. No other language, otherthan this specific phrase, is intended to invoke the provisions of thatportion of the statute.

The following explanation may identify one or more features as“optional.” This type of statement is not to be interpreted as anexhaustive indication of features that may be considered optional; thatis, other features can be considered as optional, although not expresslyidentified in the text. Finally, the terms “exemplary” or “illustrative”refer to one implementation among potentially many implementations

A. Illustrative Environment

FIG. 1 shows an illustrative environment 100 that provides personalusage information to a particular user who is operating a particularuser device 102. The user device 102 includes a plurality ofapplications 104 installed thereon or otherwise accessible to the user.In one case, the personal usage information identifies an amount of datathat each of the applications 104 has consumed within a prescribedperiod of time. For example, the environment 100 can specify that, at aparticular time, a first application (“Appln 1”) has consumed X amountof data, a second application (“Appln 2”) has consumed Y amount of data,a third application (“Appln 3”) has consumed Z amount of data, and soon. As used herein, an application that is run by the user device 102“consumes” data when it causes data to be communicated over wirelesscommunication infrastructure, e.g., either by receiving the data fromany remote entity or sending the data to any remote entity. For example,a media-related application that receives and processes a video itemconsumes an amount of data on that occasion corresponding to the size ofthe video item.

The environment 100 also provides expected usage information to the userregarding a candidate application that the user has not yet installed onthe user device 102 or otherwise run. As used herein, the expected usageinformation describes an amount of data that the candidate applicationis expected to consume when it is executed. The environment 100 canderive the expected usage information by monitoring how much data thecandidate application consumes when utilized by a group of users (whohave used the candidate application). Alternatively, or in addition, theenvironment 100 can derive the expected usage information based onsimulated usage data. The environment 100 may choose to simulate the useof the application when the candidate application has not yet been usedby a significant number of users (or by any users). Alternatively, or inaddition, a developer who develops an application can provide expectedusage information for the application.

The above-summarized application-level dissemination of personal andexpected usage information may provide a useful monitoring service withrespect to any type of data plan. But the environment 100 may conferparticular benefits in those scenarios in which a wireless communicationprovider (a “provider”) places constraints on the amount of data that auser may consume (without paying additional usage-related fees). Forexample, in some data plans, the provider may allow the user to consumeup to a threshold amount of data within a billing cycle without payingadditional fees. In a more transaction-based data plan, the provider mayask the user to pay for each individual transaction in which data isconsumed.

More specifically, the user can use the personal usage information togain insight regarding the prior data-consumption demands of theapplications 104. Armed with this information, the user can then makeintelligent decisions regarding his or her future use of theapplications 104. For example, the user may decide to reduce the use ofa high-consumption application to avoid depleting a total amount of datathat has been allocated by the user's data plan (that is, prior to theend of a billing cycle).

The user can use the expected usage information to gain insightregarding how much a candidate application will consume if placed inuse. The user may use this information to forgo using certainapplications, or by using certain high-consumption applications in ajudicious and measured manner.

In the above examples, the environment 100 assesses the usage ofapplications based on the amount of data they consume. But, moregenerally, the environment 100 can assess the usage of applicationsbased on the amount of any resource or resources that the applicationsconsume. For example, the usage of applications can also (oralternatively) be assessed based on the amount of energy they consume(e.g., which may correlate to the applications' respective use ofbattery resources). In this context, the personal usage information mayalso (or alternatively) include energy-related personal usageinformation which reflects the amount of energy that has been consumedby a particular application when used by a particular user. And theexpected usage information may also (or alternatively) includeenergy-related expected usage information which reflects the amount ofenergy that is expected to be consumed by the candidate application.However, to simplify and facilitate explanation, the followingdescription will mainly assume (unless otherwise expressly noted) thatthe personal usage information corresponds to data-related personalusage information, and the expected usage information corresponds todata-related expected usage information.

In certain implementations, the environment 100 can provide theabove-described services to the user using functionality provided by theuser device 102 itself and a processing system 106. In certain physicalimplementations, the processing system 106 represents functionality thatis provided at a remote location with respect to the user device 102.For example, the user device 102 may communicate with the processingsystem 106 via a communication conduit 108. FIG. 2, described below,provides additional detail regarding this physical implementation ofenvironment 100.

In other physical implementations, at least some of the functionsperformed by the processing system 106 can be performed by the userdevice 102 itself (and vice versa). That is, although FIG. 1 shows theprocessing system 106 and the user device 102 as distinct respectiveentities, certain functions of the processing system 106 can beconsidered as components of the user device 102 (and vice versa).Nevertheless, to facilitate explanation, most of the examples whichfollow make the simplifying assumption that the processing system 106represents a remote entity with respect to the user device 102.

With the above overview, the following explanation will describe each ofthe components illustrated in FIG. 1, starting with the user device 102.

The applications 104 represent any type of functionality for performingany respective tasks. In some cases, the applications 104 performhigh-level tasks. To cite representative examples, a first applicationmay perform a weather-reporting task, a second application may perform avideo presentation task, a third application may perform a text editingtask, and so on. In other cases, the applications 104 performlower-level management or support tasks. For example, some of theapplications 104 may represent components of a device operating system110 of the user device 102. The applications 104 can be implemented inany manner, such as by executable code, script content, etc., or anycombination thereof.

FIG. 1 shows that the applications 104 may run on the user device 102.In this implementation, to execute the applications 104, the user device102 may rely on resources provided by the device operating system 110.In another implementation, the applications 104 may represent remotefunctionality that is provided, at least in part, by a remote system(such as the processing system 106). For example, at least some of theapplications 104 may represent websites, web pages, or web applications,etc. The user device 102 executes an application of this type byaccessing it and initiating its functions. To facilitate explanation,however, the description will generally make the simplifying assumptionthat the applications 104 are installed on the user device 102.

Further, in some cases, an application refers to the entire body offunctionality which performs all tasks associated with a mainapplication task. But in other cases, an application may refer to partof a more inclusive body of functionality. For example, consider anapplication that performs a real estate search function. Onesub-application in that main application may perform a mortgagecalculation function. Another sub-application in that main applicationmay perform a map search function, and so on.

The user device 102 may also include a reporting module 112. Thereporting module 112 captures events that reflect the amount of datathat each application is consuming at any given time. According to theterminology used herein, these events constitute actual usage data,where the qualifier “actual” indicates that the usage data reflects theactual use of an application, rather than the simulated use of theapplication. The reporting module 112 can store the actual usage data ina temporary store 114. The reporting module 112 can then periodicallytransfer the actual usage data to the processing system 106 foranalysis. This disclosure provides additional details regarding thereporting module 112 in the context of the explanation of FIG. 3, below.

The user device 102 also includes a usage management module 116. Theusage management module 116 performs various functions which will bedescribed in detail in the context of the explanation of FIG. 6, below.As one function, the usage management module 116 presents personal usageinformation to a user upon the occurrence of a triggering event. Forexample, as one type of triggering event, the user may expressly requestthe personal usage information. Or the user may activate one of theapplications 104, which prompts the usage management module 116 torequest the personal usage information. As summarized above, thepersonal usage information itemizes the amount of data that eachapplication has consumed within a specified period of time.Alternatively, or in addition, the processing system 106 can implementthe usage management module 116. A user can use his or her user device102 (or any other device, such as a personal computing device) to accessthe services associated with the remotely-located usage managementmodule 116.

Now referring to the processing system 106, this functionality includesa receiving module 118 for receiving the actual usage data from aplurality of user devices, including the representative user device 102.The receiving module 118 parses the actual usage data and stores theactual usage data in an event store 120. In the case in which theapplications 104 correspond to remote resources (e.g., web pages, etc.),the receiving module 118 can receive the actual usage data from whateversystem runs the applications 104.

A usage analysis module 122 retrieves the actual usage data from theevent store 120 and performs analysis on this data. For example, amongother analysis functions, the usage analysis module 122 generates thepersonal usage information for a user. In addition, or alternatively,the usage analysis module 122 can derive the expected usage informationfor each candidate application that a user may download and install inhis or her user device. In one implementation, the usage analysis module122 can generate the personal usage information and the expected usageinformation in an on-demand manner, e.g., at the time when a userrequests this information. Alternatively, or in addition, the usageanalysis module 122 can generate the personal usage information and theexpected usage information as a background task, that is, prior to thepoint in time at which this information is requested by a user. Thisdisclosure will provide additional details regarding the functionsperformed by the usage analysis module 122 in the context of theexplanation of FIG. 4, below.

The processing system 106 also may include a marketplace system 124. Themarketplace system 124 provides an application store 126 that stores aplurality of candidate applications that can be downloaded (or otherwiseutilized) by users upon request by the users. The marketplace system 124also provides descriptive details regarding each of the candidateapplications. A user can review the descriptive details pertaining to aparticular candidate application to decide whether it is appropriate todownload (or otherwise utilize) that application. Part of thedescriptive details identifies the expected usage information for thecandidate application. The marketplace system 124 can obtain theexpected usage information from the usage analysis module 122. A usercan access the marketplace system 124 through the usage managementmodule 116 or through some other access mechanism (besides the usagemanagement module 116). This disclosure will provide additional detailsregarding the functions performed by the usage marketplace system 124 inthe context of the explanation of FIG. 5, below.

FIG. 2 shows one system 200 which implements the environment 100 ofFIG. 1. The system 200 includes a plurality of user devices 202 of anytype. Any user device may represent any type of computing functionalitythat has the capability of communicating with a remote entity viawireless communication. For example, any user device may represent anytype of portable device having a wireless communication interface,including a cellular telephone of any type (e.g., a smart phone), apersonal digital assistant device, an electronic book reader device, aportable game console device, a laptop or netbook-type computing deviceof any size, a tablet-type device, a vehicle-borne navigation device,and so on. Alternatively, the user device may represent any type oftraditionally stationary computing device having a wirelesscommunication interface, such as a personal computer, a game consoledevice, a set-top box device, and so forth.

The communication conduit 108 can represent any mechanism or combinationof mechanisms that allows the user devices 202 to communicate withremote entities (and to communicate with each other). Generally stated,the communication conduit 108 can represent any local area network, anywide area network (e.g., the Internet), or any combination thereof. Thecommunication conduit 108 can be governed by any protocol or combinationof protocols.

At least part of the communication conduit 108 can be implemented bywireless communication infrastructure 204. In one case, the wirelesscommunication infrastructure 204 can represent a collection of celltowers, base stations, satellites, etc. The wireless communicationinfrastructure 204 can be administered by one or more wirelesscommunication providers. Each provider may interact with its customersusing prescribed protocols and formats. The communication conduit 108can also include wired network infrastructure.

In one implementation, the processing system 106 may represent one ormore server computing devices and associated data stores (and otherelectronic equipment). The processing system 106 can be implemented at asingle site or can be distributed over multiple sites. Further, theprocessing system 106 can be administered by a single entity or bymultiple entities. For example, in one case, a single physical systemcan implement both the usage analysis module 122 and the marketplacesystem 124. In another case, two or more systems can implement the usageanalysis module 122 and the marketplace system 124. Further, asexplained above, any functions described as being performed by theremote processing system 106 can instead (or in addition) be performedby the user devices 202, and vice versa.

The system 200 can also include one or more other systems 206 that mayinteract with the processing system 106 and/or the user devices 202. Forexample, the other systems 206 can include computer infrastructuremaintained by an application developer. The developer can use itscomputer infrastructure to access the processing system 106 to obtaindetailed usage information regarding the usage-related behavior of anapplication that is has developed. Based on this insight, the developermay decide to modify its application in any manner. For example, thedeveloper may modify the application to improve the efficiency at whichit consumes data.

Finally, FIG. 2 shows that any user can use any separate user device 208to access usage information provided by the processing system 106, e.g.,by accessing a remote service provided by the processing system 106. Forexample, the user device 208 may represent a personal computing devicethat the user uses to access online-usage data, whereas the user uses asmart phone to actually run applications and consume data under his orher plan. In this scenario, the user device 208 may not have a usagemanagement module 116 installed thereon.

FIG. 3 shows one illustrative implementation of the reporting module 112introduced in the context of the description of FIG. 1. The reportingmodule 112 includes an event collection module 302 for collecting actualusage data from one or more event sources 304, e.g., either on a pullbasis, a push basis, or combination thereof. The event sources 304correspond to any type of mechanisms within the user device 102 thatcapture information that evidences the consumption of data by the userdevice 102. For example, in some cases, the event sources 304 maypertain to event-generating instrumentation code added to applications,operating system functionality, and/or other components of the userdevice 102.

The actual usage data that is collected can encompass different types ofdata. One type of actual usage data describes socket-related activityperformed by the user device 102. Another type of actual usage dataconveys application information (which identifies each application thatis being executed at a given time). Another type of actual usage dataconveys network interface information (which identifies the type ofnetwork interface mode that each application is using to interact with aremote entity, such as 3G or WiFi). Other types of actual usage data maydescribe push notification activity, background transfer serviceactivity, video streaming activity, and so on. The above-described typesof actual usage data are representative, not exhaustive; otherimplementations can collect additional types of actual usage data, oromit one or more types of actual usage data mentioned above.

In the above-described implementation, the event collection module 302collects the actual usage data solely based on activity that occurswithin the user device 102. In addition, or alternatively, otherentities within the environment 100 can collect information thatreflects the consumption of data by an application running on a userdevice. For example, any entity that is part of the wirelesscommunication infrastructure 204 can also collect actual usage data.Alternatively, or in addition, the processing system 106 can collectactual usage data, particularly in those cases in which an applicationis a remote application that actually runs on the processing system 106,rather than on the user device 102. Nevertheless, to facilitateexplanation, it will henceforth be assumed that the environment 100collects the actual usage data from the user devices.

As described above in connection with FIG. 1, the event collectionmodule 302 stores the actual usage data in a temporary store 114. Anevent forwarding module 306 can compress the actual usage data stored inthe temporary store 114 (before or after storage of the data). Then, ata prescribed reporting time (e.g., every 30 minutes in one merelyrepresentative case), the event forwarding module 306 can transfer thecompressed actual usage data to the processing system 106. The eventforwarding module 306 can perform this transfer via the communicationconduit 108, which, as said, may rely on the services of the wirelesscommunication infrastructure 204.

A management module 308 generally governs the operation of the reportingmodule 112. For example, the reporting module 112 can maintain aregistry of available event sources 304. Based on configurationinformation, the reporting module 112 can then activate or deactivateindividual event sources. If deactivated, an event source will notcontribute actual usage data that is stored in the temporary store 114.

The reporting module 112 can use various mechanisms to implement thereporting module 112. For example, in one non-limiting implementation,the reporting module 112 can use Event Tracing for Windows® (ETW) toimplement the reporting module 112, provided by Microsoft® Corporationof Redmond, Wash. ETW represents kernel-level functionality for loggingevents, typically employed for debugging or testing the performance ofapplications.

FIG. 4 shows one illustrative implementation of the usage analysismodule 122 provided by the processing system 106. The usage analysismodule 122 can maintain a usage data store 402 that stores usage data.As used herein, usage data refers to any information that the usageanalysis module 122 can use to generate personal usage information orexpected usage information (and other types of usage information). Forexample, the reporting module 112 of each user device can provide actualusage data which contributes to the usage data that is stored in theusage data store 402.

In addition, or alternatively, a usage simulator 404 can simulate theuse of an application. This operation provides simulated usage data thatcontributes to the usage data stored in the usage data store 402. In oneimplementation, the usage simulator 404 can correspond to an emulatorwhich runs on the processing system 106. Alternatively, or in addition,the usage simulator 404 can correspond to testing functionality thatruns on one or more actual user devices (where the user devicesfunction, in this circumstance, in a simulation mode of operation). Ineither case, the usage simulator 404 may operate by automaticallyinvoking functionality provided by an application, thereby simulatingthe manner in which an actual user would manually utilize theapplication. The usage simulator 404 can use any simulation routine tosimulate an application, including a routine that applies a predefinedsequence of activations, a routine that applies a random selection ofactivations, or a combination thereof. A reporting module (not shown)can then collect simulated usage data which expresses the data consumedduring the simulation operation. As will be described below, the usageanalysis module 122 can rely on the simulated usage data in those casesin which actual usage data is not available, or is not available insuitable abundance.

Another collection module 406 can collect supplemental usage data andadd that data to the usage data store 402. More specifically, thesupplemental usage data provides information which has a bearing on thecomputation of personal and expected usage information (and other usageinformation), but does not directly express the consumption of data. Forexample, the collection module 406 can collect user profile data forusers who operate the user devices 202. For each user, the user profiledata expresses the manner in which the user typically interacts withapplications. As will be described below, the usage analysis module 122can use the user profile data to generate usage information which isparticularly germane to the behavior of individual respective users.

In one case, the collection module 406 can glean the user profile datafrom the actual usage data collected in the manner described above(e.g., as described with reference to FIG. 3). For example, based on theactual usage data, the collection module 406 can determine the types ofactions that a user typically performs while interacting with anapplication, the frequency at which the user performs those actions, andthe amount of data consumed by those actions. The collection module 406can then formulate user profile data which classifies the behavior ofthe user based on this type of evidence. The collection module 406 canalso provide information which qualifies the consumption-relatedbehavior of each user, such as by identifying the terms of the data planunder which the user has consumed the data.

More specifically, the collection module 406 can formulate the userprofile data for a user in any level of granularity. In one case, thecollection module 406 provides user profile data which classifies theamount of data that a user typically consumes while using applications,without discriminating between different types of applications. Forexample, the user profile data for a user may classify the user as ahigh-consumption data user because that user has a demonstratedproclivity to consume large-content items (such as video items) whileusing applications in general; in addition, or alternatively, that usermay be regarded as a high-consumption data user because he or she sendsand/or receives a large quantity of messages while using applications ingeneral, and so on.

In another case, the collection module 406 can determine the user'sconsumption-related behavior in the course of interacting with differenttypes of applications. For example, the collection module 406 candetermine the frequency at which the user downloads large-content itemswhile using social networking applications, as opposed to news-relatedapplications. Based on this insight, the collection module 406 canclassify the user's behavior with respect to different types ofapplications. For example, the user's profile data may indicate that theuser is a high-consumption data user with respect to social networkingapplications, but a medium-consumption data user with respect to allother types of applications. The collection module 406 can use any othercriterion or criteria to categorize some aspect of theconsumption-related behavior of each user.

In the above examples, the collection module 406 derives the userprofile data for a user based on a direct evidence of the amount of datathat the user consumes while using applications. Alternatively, or inaddition, the collection module 406 can use indirect factors to gaugethe user's proclivity to consume data while using an application.Representative factors include the number of contacts that the usermaintains on a social networking site, the number of Email accounts thatthe user syncs together while using certain applications, demographicinformation regarding the user (such as age, place of residence,organizational affiliations, etc.), and so on.

The collection module 406 can also collect plan data for each user thatexpresses the nature of the data plan that governs the user'sconsumption of data. For example, the plan data for a particular usermay describe the billing cycle for that user, the data limits for thatuser, and so on. The collection module 406 can obtain the plan data indifferent ways. In one approach, the collection module 406 can obtainthe plan data from a user when the user manually provides thisinformation. In another approach, the collection module 406 can obtain auser's plan data from whatever entity administers the plan, such as awireless communication provider that provides service to the user. Forexample, the collection module 406 can query the wireless communicationprovider by sending a particular request message. That request message,for example, can be formulated as an SMS message or the like. Thewireless communication provider responds by providing plan data for theuser. In another approach, the collection module 406 may communicatedirectly with a billing system of the wireless communication provider.As will be described below, the usage analysis module 122 can formulatethe usage information in relation to the plan data. This gives the useran appreciation of the consequences of his or her data usage in thecontext of the constraints imposed by his or her data plan.

The examples of supplemental usage data provided above arerepresentative, not exhaustive. That is, the collection module 406 cancollect additional types of supplemental data which has a bearing on theanalysis performed by the usage analysis module 122.

An energy monitor module 408 can optionally also provide energy-relatedactual usage data (whereas the usage data described so far pertains todata-related actual usage data). More specifically, an application mayperform various functions, such as powering up the display, using theCPU, and transferring information over a network. The energy monitormodule 408 can measure the amount of energy that each of these functionsconsumes, and then sum up all of these energy expenditures to provide anindication of the total amount of energy that has been consumed by theapplication. The energy monitor module 408 can measure energyexpenditure in various ways, such as by monitoring battery voltage levelor some other battery-related metric. Alternatively, or in addition, theenergy monitor module can use models to convert loads placed ondifferent components of the mobile device 102 into energy expenditures.The usage analysis module 116 can use the energy-related usageinformation to provide energy-related personal usage information andenergy-related expected usage information. (However, to simplify theexplanation, the environment 100 of FIG. 1 will continue to be mainlydescribed based on the assumption that the actual usage data measuresthe consumption of data, not energy.) Note that an application'sconsumption of energy implicates all processes that the applicationperforms, not just the transfer of data via a network. However, it isalso possible to generate an energy measurement that pinpoints theamount of energy an application consumes sending and receiving data overa network.

The usage analysis module 122 also includes an analysis module 410 forderiving the personal usage information and/or the expected usageinformation based on the usage data described above. The manner in whichthe analysis module 408 performs this function will be set forth belowin the context of the explanation of FIG. 7.

Finally, the usage analysis module 122 can include an entity interfacemodule 412. The entity interface module 412 provides interfacefunctionality which allows any entity to interact with the usageanalysis module 122. Such entities can include any user device, adeveloper system (administered by a developer), and so on.

FIG. 5 shows one illustrative implementation of the marketplace system124 provided by the processing system 106 or some other component withinthe environment 100. The marketplace system 124 may represent one ormore server computers and associated data stores.

The marketplace system 124 includes an application receipt andpre-processing module 502 (simply “receipt module” 502 below forbrevity). The receipt module 502 can receive applications of any typefrom any sources for storage in the application store 126. For example,the receipt module 502 can receive applications from ordinary end users,professional application developers, and so on. The receipt module 502can also perform optional pre-processing on the applications prior tostorage; for example, the receipt module 502 can analyze theapplications to determine whether they pose a security threat. Theapplications stored by the application store 126 are referred to ascandidate applications because these applications are candidates fordownloading by the users (and/or online use by the users). Themarketplace system 124 can also store descriptive metadata associatedwith each candidate application.

The marketplace system 124 also includes an application search module504. The search module 504 allows a user to navigate within theapplication store 126 to find a candidate application that meets his orher needs. Such navigation is performed on the basis of the descriptivemetadata associated with the candidate applications. For example, a usercan use the application search module 504 to browse through differentcategories of applications. Alternatively, or in addition, the user canuse the application search module 504 to identify applications thatsatisfy a specified search term, and so on. Upon identifying apotentially suitable candidate application, the application searchmodule 504 can supply the user with any level of descriptive detailregarding the candidate application.

For example, as one category of detail, a usage presentation module 506can reveal the expected usage information associated with a candidateapplication. As described above, the expected usage informationdescribes the amount of data that an application is expected to consumewhen used by a particular user. The examples which follow clarify themanner in which the environment 100 can derive and apply the expectedusage information.

An application acquisition module 508 allows a user to acquire anapplication that satisfies the user's needs. For example, the user caninteract with the application acquisition module 508 to purchase anddownload an application (or otherwise gain access to the application),or to simply download or access the application if it is available freeof charge.

Finally, an entity interface module 510 provides an interface thatallows any entity to interact with the marketplace system 124. One suchentity may correspond to an individual user who is operating his or heruser device.

FIG. 6 shows one illustrative implementation of the usage managementmodule 116 provided by each user device, such as the representative userdevice 102 of FIG. 1. The usage management module 116 generally performsall functions of the user device 102 which have a bearing on thepresentation of usage information. Alternatively, one or more aspects ofthe usage management module 116 can be performed by the processingsystem 106. This is the case, for instance, when the usage managementfunctionality is implemented as an online service.

The usage management module 116 includes a user interface module 602 forinteracting with the user. For example, the user interface module 602may include functionality for displaying information to the user via adevice screen and/or other output mechanism(s). The user interfacemodule 602 may also include functionality for receiving information froma user, e.g., via a keypad, a touch-sensitive input screen, a mousedevice, and/or other input mechanism(s).

A processing system interface module 604 allows the usage managementmodule 116 to exchange information with the processing system 106 and/orany other entity within the environment 100. For example, the usagemanagement module 116 can receive personal usage information and/orexpected usage information from the processing system 106 via theprocessing system interface module 604.

Generally, the usage management module 116 can exchange data with theprocessing system 106 via any transmission mechanism, such as, but notlimited to, an SMS transmission mechanism. Further, the wirelesscommunication infrastructure 204 which couples the usage managementmodule 116 to the processing system 106 may specify the use of certainformats and protocols. In view thereof, the processing system 106 canparse and structure the information that it sends to the usagemanagement module 116 in an appropriate provider-specific manner.

The usage management module 116 can include a usage presentationtriggering module 606. As the name suggests, the usage presentationtriggering module 606 detects when an event has occurred which triggersthe presentation of usage information. In one case, the usagepresentation triggering module 606 triggers the presentation of personalusage information when the user explicitly requests this information orwhen the user activates an application. In another case, the processingsystem 106 provides expected usage information when the user accessesthe marketplace system 124.

A presentation module 608 controls the manner in which usage informationis displayed to a user (or presented to the user in some other form).For example, as will be described in greater detail below, thepresentation module 608 can present the usage information in textualform, graphical form, or some combination thereof.

A configuration module 610 allows the user to configure the manner inwhich the usage management module 116 operates. According to one option,for instance, the configuration module 610 can allow the user to setindividual application-specific quotas for different applications. Anapplication-specific quota describes how much a given application ispermitted to consume within a billing cycle. The usage management module116 can perform various environment-specific actions when the userexceeds an application-specific quota for a billing cycle, such as byissuing a warning or other informational message, or prohibiting the useof the application, and so on.

Finally, an optional device modification module 612 can govern operationof an application based on usage information (and/or based on the rawactual usage data). For example, the device modification module 612 canmonitor the amount of data that a particular application has consumed.If the usage exceeds a prescribed threshold or exhibits other thresholdbehavior, the device modification module 612 can change the way that theapplication operates to make it more efficient in its consumption ofdata. For example, the device modification module 612 can reduce theresolution of video items that are being presented to the user.Alternatively, or in addition, the device modification module 612 candisable or otherwise limit the use of certain application features thatconsume a significant amount of data. For example, the devicemodification module 612 can disable or restrict the ability of anapplication to present ads to a user during use. More specifically, insome cases, the device modification module 612 can make a change bymodifying an application itself. Alternatively, or in addition, thedevice modification module 612 can make a change by modifying otherresources provided by the user device 102, on which the applicationrelies.

As a footnote, FIG. 1 shows that the reporting module 112 and the usagemanagement module 116 represent separate components. However, in anotherimplementation, the reporting module 112 may represent a componentwithin the usage management module 116.

FIG. 7 shows a high-level view of analysis logic 702 and usagepresentation logic 704. The analysis logic 702 performs analysis onusage data to derive usage information (e.g., either personal usageinformation or expected usage information). The usage presentation logic704 formulates the usage information into a particular form forpresentation to a user. Different components within the environment 100of FIG. 1 can implement the analysis logic 702 and the usagepresentation logic 704. For example, FIG. 4 shows that the usageanalysis module 122 can employ an analysis module 410 that can implementaspects of the analysis logic 702. FIG. 5 shows that the marketplacesystem 124 can employ a presentation module 506 that can implementaspects of the usage presentation logic 704. And FIG. 5 shows that theusage management module 116 can employ a presentation module 608 thatalso employs aspects of the usage presentation logic 704. More generallystated, the environment 100 can distribute the analysis logic 702 andthe usage presentation logic 704 to different components of theenvironment 100 in any manner based on any environment-specificconsiderations. As such, any of the analysis and presentation functionsdescribed herein can be performed locally and/or remotely with respectto a user device. In the following description, the term “particularuser” refers to the user for whom the usage information (e.g., eitherthe personal usage information or the expected usage information) isprovided. Other users besides the particular user are “other users.”

FIG. 7 identifies various options that govern the operation of theanalysis logic 702. For example, FIG. 7 indicates that the analysislogic 702 can generate usage information based on various types of inputdata. One type of input data corresponds to actual usage data. In mostof the examples that follow, the actual usage data corresponds todata-related actual usage data; but it can alternatively, or inaddition, correspond to energy-related usage data. Another type of inputdata corresponds to simulated usage data. Although not enumerated, theanalysis logic 702 can depend on yet further types of input data.

FIG. 7 also indicates that the analysis logic 702 can generate usageinformation based on various types of qualifying considerations. Onetype of qualifying consideration corresponds to plan data whichspecifies a manner in which a user is permitted to consume data based ona contractual data plan. Another type of qualifying considerationcorresponds to user profile data which characterizes the manner in whichusers typically consumes data while using applications. Although notenumerated, the analysis logic 702 can depend on yet further types ofqualifying considerations.

FIG. 7 also indicates that the analysis logic 702 can generate differenttypes of usage information. In one case, for instance, the analysislogic 702 can generate personal usage information which reflects theamount of data that each application installed on the user device 102has consumed within a prescribed period of time. In another case, theanalysis logic 702 can present the personal usage information inconjunction with projected usage information. The analysis logic 702 canform the projected usage information by extending or extrapolating thepersonal usage information into the future, based on the assumption thatthe user's future consumption of data will resemble the user's recentconsumption of data.

In another case, the analysis logic 702 can present comparison usageinformation in conjunction with the personal usage information. Theanalysis logic 702 can provide the comparison usage information as abenchmark against which a user can evaluate his or her personal usageinformation. In one implementation, the analysis logic 702 can computethe comparison usage information for a particular application for aparticular user (who operates a particular user device) by processingthe actual usage data provided by a group of other user devices whichalso run the particular application. As will be described below, thisprocessing of usage data can be performed in various ways, e.g., byforming an average or a median value, etc.

In another case, the analysis logic 702 can generate expected usageinformation which refers to the amount of data that a candidateapplication is expected to consume when it is used by a particular user.The analysis logic 702 can form the expected usage information in thesame manner as the comparison usage information, e.g., by processing theactual usage data provided by a group of user devices which have run thecandidate application. Alternatively, or in addition, the analysis logic702 can form the expected usage information based on simulated usagedata (at least in part). Alternatively, or in addition, a developer whodevelops an application can provide expected usage information for theapplication.

The analysis logic 702 can also optionally tailor the comparison usageinformation and the expected usage information in a manner which takesaccount of the user profile data associated with the particular user whowill receive the usage information, as well as the user profile dataassociated with a group of other users.

In another case, the analysis logic 702 can generate per-functiondetailed usage information. This usage information identifies the amountof data consumed by individual functions within a particular applicationthat involve wireless communication. In one scenario, a developer mayrequest this type of information to gain insight regarding how theapplication may be modified to improve its efficiency.

Further, any of the categories of usage information described above canbe expressed in the context of energy usage, as opposed to data usage(or in addition to data usage). For example, the analysis logic 702 cangenerate energy-related personal usage information and energy-relatedexpected usage information. And this energy-related information can betailored based on user profile data in the manner described above.

FIG. 7 also identifies various options that govern the operation of theusage presentation logic 704. For example, as stated above, the usagepresentation logic 704 can present the usage information in alphanumericform or graphical form, or combination thereof. The usage presentationlogic 704 can also present the usage information with reference to anytime interval, such as a monthly billing cycle. In some cases, the usagepresentation logic 704 can also express the usage information in summaryform, e.g., as a summary badge.

FIGS. 8-15 depict examples of the output of the analysis logic 702 andthe usage presentation logic 704. In each case, the user device 102 maypresent the output on a display screen 802 of the user device 102. Forexample, in the case of a smart phone or the like, the display screen802 may also function as a touch-sensitive input mechanism. The user mayphysically interact with the display screen 802 to navigate within theservices provided by the usage management module 116. Alternatively, orin addition, the user can use a personal computing device or some otherstationary computing device to access the usage information.

In scenarios A-G (in FIGS. 8-10), the environment 100 presents personalusage information to the particular user who is using the user device102. The personal usage information itemizes how much data eachapplication that is installed on (or otherwise accessible to) the userdevice 102 has consumed thus far within a current billing cycle.Scenarios A-G convey this information in different ways, describedbelow. Although the various scenarios adopt different respectivepresentation strategies, any scenario can combine two or more of thepresentation strategies described herein.

In scenario A, the environment 100 presents a single value for eachapplication. That single value identifies the amount of data that eachapplication has consumed within the current billing cycle.

In scenario B, the environment 100 presents two values for eachapplication. A first value identifies how much data an application hasconsumed using a first network interface mode (e.g., 3G communication),while a second value identifies how much data the application hasconsumed using a second network interface mode (e.g., WiFicommunication) (where 3G communication is typically more expensive thanWiFi communication). Although not shown, the environment 100 can alsoidentify the particular network entities that are associated with anynetwork interface mode. For example, assume that a user regularly uses afirst wireless communication provider when using his user device in hishome state, but uses a second wireless communication provider when at abusiness site in another state. In this circumstance, the environment100 can break down the cellular data usage for each wirelesscommunication provider.

In scenario C, the environment 100 presents a single value thatidentifies the amount of data that each application has consumed; but inthis case, the environment 100 also conveys the application-specificquota for the application. The user (or other entity) may specify thisapplication-specific quota via the configuration module 610 of FIG. 6.

Scenario D (in FIG. 9) uses a graphical format to convey the amount ofdata that an application has consumed, relative to a total amount ofdata that has been allocated to the application, e.g., as expressed bythe application-specific quota described above. In this example, theenvironment 100 uses a pie chart to convey the fraction of theapplication-specific quota that has been consumed by the application,but the environment 100 can use any other suitable graphical format orcombination of formats (such as a bar chart or the like) to convey thisinformation.

In scenario E, the environment 100 also conveys the amount of data thatan application has consumed in graphical form. But in scenario E, theenvironment 100 also extends the personal usage information to providean indication of when the user is expected to reach theapplication-specific quota for the application. This extrapolation makesthe assumption that the user will continue using the application in thesame manner that he or she has up to the present point in time. ScenarioE also shows a descriptive text caption which explains the salientfeatures of the graphical depiction. According to the terminology usedherein, the information which conveys the estimated future consumptionof data by an application constitutes projected usage information.

Scenario F (in FIG. 10) uses a single value to convey the amount of datathat each application has consumed within a current billing cycle. Inaddition, the environment 100 can provide a single value for eachapplication which conveys the amount of data that other users haveconsumed while using this same application. According to the terminologyused herein, information which relates to the data consumption of otherusers constitutes an example of comparison usage information. Scenario Fpresents the personal usage information and comparison usage informationin textual form, but this information can also be presented in graphicalform (e.g., in bar chart form or the like).

In one case, the environment 100 can form comparison usage informationfor a particular application by collecting actual usage data from agroup of user devices (operated by other users) which have used theparticular application. The environment 100 then processes the actualusage data that has been collected to form the comparison usageinformation.

The processing can take various forms. For example, the environment 100can present an average value which describes the average actual datausage of the particular application by the group of user devices. Inaddition, the environment 100 can present a standard deviation valuewhich describes a standard deviation associated with the average usagevalue. In addition, or alternatively, the environment 100 can present amedian value which describes a median actual data usage of theparticular application by the group of user devices. In addition, oralternatively, the environment 100 can present distribution informationwhich represents a distribution of data usage readings received fromindividual user devices in the group of user devices. These scenariosare presented by way of example, not limitation; other implementationscan perform processing on a collection of usage data in other ways.

Scenario G also expresses personal usage information in conjunction withcomparison usage information. But in this case, the environment 100biases the comparison usage information in a manner to reflect theconsumption-related behavior of the particular user (who receives theinformation shown in Fig. G), as reflected by user profile dataassociated with this user. The environment 100 can perform this biasingor tailoring in different ways. In one implementation, the environment100 can first classify the consumption-related behavior of theparticular user. More specifically, in one case, the environment 100 candetermine the consumption-related behavior of the user with respect toall applications with which the user has previously interacted, withoutdiscriminating between different classes of applications. In anothercase, the environment 100 can determine the user's consumption-relatedbehavior with respect to a particular class of applications with whichthe user has previously interacted. For example, assume that theenvironment 100 seeks to generate comparison usage information for aparticular application, e.g., “Appln A.” The environment 100 candetermine that Appln A is a social networking application. Theenvironment 100 can then classify the consumption-related behavior ofthe user based on the manner in which the user has interacted with ApplnA as well as other social networking applications.

After classifying the particular user, the environment 100 can presentcomparison usage information which is germane to the particular user'sidentified class of consumption-related behavior. For example, assumethat environment 100 determines, over a span of time, that the usercorresponds to a high-consumption data user. The environment 100 canthen present comparison usage information for a particular application(e.g., “Appln A”) which describes or approximates the manner in whichother high-consumption data users have used Appln A.

The environment 100 can express or approximate the behavior of otherusers in various ways. In one approach, the environment 100 can identifya subset of other data users who have used Appln A and who have alsobeen classified as high-consumption data users (based on theirrespective user profile data). More specifically, in a first case, theseother users may correspond to high-consumption data users due to theirhigh consumption of applications in general; in a second case, theseusers may correspond to high-consumption data users due to theirconsumption of applications in the same class as Appln A. Theenvironment 100 can then express the comparison usage information as theaverage value of the consumption exhibited by this subset of users, orby using some other metric.

In another case, the environment 100 can form a distribution ofconsumption readings for all users who have used Appln A. Theenvironment 100 can then form the comparison usage information byextracting a representative data usage reading from the high range endof that distribution.

In yet another case, the environment 100 can form the comparison usageinformation by averaging the consumption of all users who have usedAppln A and then adding a fixed offset to this value to reflect that theparticular user is a high-consumption data user. Still other approachescan be applied to compute the comparison usage information.

In any of the examples set forth above, the environment 100 can alsotake the data plans of users into account when generating comparisonusage information (where plan data may be regarding as a component ofthe user profile data associated with the users).

That is, a user's consumption-related behavior is influenced by thecontractual terms under which a user is allowed to consume data. Forinstance, a user who has a relatively high per-month limit can beexpected to be more liberal in his or her utilization of applicationscompared to a user who pays for data usage on a per-transaction basis.Hence, the environment 100 can ascertain the data plan that governs theparticular user's consumption of data, and then formulate comparisonusage information from a subset of users who share the same data plan.This provides a more robust identification of the users who are the truepeers of the particular user.

In yet another strategy, the environment 100 can form comparison usageinformation by giving the user an indication of how much data he or shehas consumed while using applications of the same type as Appln A. Forexample, if Appln A is a social networking application, the environment100 can form comparison usage information which gives the user anindication of how much data, on average, the user has consumed whileusing other social networking applications. This comparison usageinformation thereby reveals how efficient the particular application iswith respect to other applications that perform the same basic function.This type of comparison usage information may be based on just thebehavior of the particular user, but it can also take into considerationthe usage behavior of other users.

Advancing to FIG. 11, this figure shows one manner by which theenvironment 100 can present expected usage information (regarding acandidate application that may not yet have been downloaded to theuser's user device 102). The environment 100 can present the expectedusage information to a particular user when that user accesses themarketplace system 124. For example, at some point in the user'sexploration of the available applications, assume that the environment100 presents a page 1102 to the user that provides various descriptivedetails regarding a particular candidate application. One item mayprovide a textual description of the candidate application. Another itemmay provide a review of the candidate application. Another item mayinvite the user to download or otherwise acquire the application.Another item may invite the user to investigate the expected usagecharacteristics of the candidate application. The user may wish toreview this usage information to determine the manner in which theinstallation of the application will affect the user's data consumptionbudget.

Assume that the user opts to investigate the usage informationassociated with the candidate application, e.g., by clicking on the“Usage Characteristics” link in page 1102. The environment 100 respondsby displaying the extended usage information in variousenvironment-specific ways, some of which are enumerated in FIG. 11.

For instance, in scenario 1104, the environment 100 can form theexpected usage information for a candidate application by collecting andprocessing the actual usage data provided by user devices which havealready used the candidate application. In scenario 1104, theenvironment 100 expresses the result of its processing as one or morevalues, e.g., by providing any of an average value, a standard deviationvalue, a median value, and so on, or combination thereof. In otherwords, the environment 100 can form the expected usage information inthe same way that it forms the comparison usage information in scenarioG above.

In scenario 1106, the environment 100 can again convey the expectedusage information using one or more values. But in this case, theenvironment 100 presents expected usage information that is tailored tothe usage habits exhibited by the particular user (who will receive theexpected usage information). The environment 100 can formulate thisbiased expected usage information in any of the ways described abovewith respect to scenario G. That is, the environment 100 can assess theusage-related behavior of the particular user, either in anapplication-agnostic manner (without isolating the user's behavior withrespect to different classes of applications) or in anapplication-specific manner (by selectively considering the user'sbehavior with respect to a specific class of applications to which thecandidate application belongs). (In this case, however, the environment100 does not consider the manner in which the user has interacted withthe candidate application, because the user has not yet had anopportunity to interact with this application.) In one case, theenvironment 100 can then generate the expected usage information basedon the data usage of other users who share the particular user's dataconsumption habits (as reflected by their user profiles), and who havealso used the candidate application in question. In addition, theenvironment 100 can generate the expected usage information byconsidering only those other users who are governed by the same type ofdata plan as the particular user.

In scenario 1108, the environment 100 can present a badge that conveysthe expected usage information in summary fashion. The badge correspondsto any kind of graphical object. For example, in the case of FIG. 11,the environment 100 presents a summary badge which indicates that thecandidate application is rated “application light,” meaning that,relatively speaking, the candidate application is not expected toconsume a large quantity of data in use. The environment 100 canclassify the candidate application in this manner by again taking intoaccount the manner in which other users have interacted with thecandidate application. For instance, the environment 100 can form anaverage value that represents the average consumption of the otherusers, and then determine what range this average value falls within;the environment 100 can then assign a summary badge corresponding to theidentified range. The environment 100 can classify the candidateapplication in this manner with or without taking into considerationuser profile data.

Alternatively, or in addition, the environment 100 can express how thecandidate application compares with other applications that perform thesame basic function as the candidate application. The environment 100can compute this metric by generating usage information for thecandidate application and then generating usage information for otherrelated applications. (The usage information for other relatedapplications can take into consideration the behavior of the particulartarget user and other users, or just the particular user, or just theother users.) The environment 100 can then present information whichreflects the usage difference between the candidate application and itspeer applications. For example, the environment 100 can express twonumbers which reflect the usage of the candidate application and theusage of its peers, respectively. Alternatively, or in addition, theenvironment 100 can provide a summary badge which reflects the relativeefficiency of the candidate application with respect to its relatedapplications. For example, the environment 100 can rate the data usageof a video editing candidate application relative to the data usage ofother video editing applications. A summary badge provides an indicationof whether the candidate application is data-efficient within its classof related applications.

In scenario 1110, the environment 100 presents the expected usageinformation in the form of a distribution of data usage readings,instead of (or in addition to) an average value or the like (as in thecase of scenario 1104). For example, the environment 100 can express thedistribution as a histogram which identifies the range of behavior amongusers who have used the candidate application. Again, this distributioncan be generated with or without taking into consideration user profiledata.

In scenario 1112, the environment 100 presents expected usageinformation for a new or otherwise rarely-used candidate application.The environment 100 can formulate the expected usage information in thiscircumstance based on simulated usage data, or based on a combination ofsimulated usage data and actual usage data. The usage simulator 404 ofFIG. 4 provides the simulated usage data. More specifically, in onecase, the environment 100 can compute the expected usage informationbased on a weighted combination of the actual usage data and thesimulated usage data. A weight applied to the simulated usage datadecreases as additional actual usage data is obtained.

Advancing to FIG. 12, this figure shows a scenario in which theenvironment 100 presents data-related personal usage information inconjunction with energy-related personal usage information. Thedata-related personal usage information may not necessarily track theenergy-related personal usage information because the energy-relatedpersonal usage information measures all of the energy consumed by theapplication, not just the energy consumed in performing data transfers.However, it is also possible to generate energy-related personal usageinformation which specifically targets application functions whichperform data transfers. The information imparted by FIG. 12 allows auser to gain insight as to the financial cost of running theapplication, as well as the extent to which the application will drainthe battery of the user device 102 when running. Although not shown, anytype of expected usage information shown in FIG. 11 can be expressed inthe context of energy usage, rather than (or in addition to) data usage.

FIG. 13 shows a scenario in which the environment 100 presents moredetailed application-level usage personal information to a user (orother entity) compared to the previous examples. More specifically, theenvironment 100 can generate usage information which identifies thefunctions associated with each application and the amount of data thateach function has consumed. A function consumes data when it sends orreceives data via the wireless communication infrastructure 204. Somefunctions may correspond to foreground tasks while other processes maycorrespond to background tasks. A foreground task refers to a functionthat directly serves a main purpose of the application. A backend taskrefers to a function that performs a tangential function with respect tothe overriding purpose of the application. For example, a user mayinteract with a social networking application to interact with his orher friends, e.g., by sharing messages and video items with the friends.This activity represents a foreground task because it carries out theuser's principal purpose in interacting with the application. But thatsame application may also devote a certain amount of network activity topresenting ads to the user while the user uses the social networkingfunctions. This activity represents a background task because it is notperformed in direct response to the user's instruction, and maytherefore occur without the user even interacting with the application.

A user can apply the insight provided by the per-function usageinformation shown in FIG. 13 in various ways. For example, a user maydecide to terminate (or reduce the use of) an installed application thatconsumes a significant amount of data in performing background tasks orotherwise extraneous tasks. Or a user may decline to download acandidate application which exhibits high data usage for backgroundtasks. The environment 100 can also provide per-function usageinformation expressed in terms of energy consumption.

The environment 100 can also optionally summarize the data efficiency ofan application with a summary badge or some other graphical object orscore. The data efficiency may express, among other considerations, theportion of data consumed in foreground tasks relative to the portion ofdata consumed in background tasks. In addition, or alternatively, thedata efficiency may express the amount of background consumption of theparticular application relative to the background consumption of relatedapplications that perform the same basis task.

In FIG. 14, the environment 100 formulates personal usage information interms of data type. That is, in this particular example, the environment100 identifies different types of data, including text, image, audiostreaming, video streaming, etc. The environment 100 then conveys howmuch of each type of data the user device 102 has consumed so far in abilling cycle. Although not shown, the environment 100 can also presentthis data on a per-application basis, or a per-application-class basis.In addition, the environment 100 can present comparison usageinformation which reflects the per-data-type data usage of a group ofother users.

FIG. 15 shows a scenario in which the environment 100 may presentper-function usage information that is even more detailed compared tothe case of FIG. 13. For example, in the case of FIG. 15, theenvironment 100 can also identify the network entities associated withdifferent transactions that consume data within an application. Thatinformation is referred to as entity identification information herein.In one case, the network entities may be identified by examining thedestinations which receive data and/or sources which provide data; inanother case, the network entities may be identified by examining therespective ports of the user device 102, and so on. In some cases, theentity identification information may reveal the agents in a networktransaction that are financially benefiting from the transaction.

A developer or other entity may request the per-function usageinformation shown in FIG. 15 with the objective of modifying the mannerin which a corresponding application consumes data. For example, adeveloper may find that a certain function of an application isconsuming an excessive amount of data, e.g., because it involvesredundant or otherwise inefficient network transactions or the like. Thedeveloper may therefore choose to redesign certain features of theapplication to make it more efficient. In general, the developer canmodify the application in any manner, e.g., by changing the manner inwhich it performs data compression, the manner in which it performs datacaching, and so on. Alternatively, or in addition, the developer maysimply eliminate or reduce the use of certain functions.

Alternatively, or in addition, the developer can modify an applicationto change the network entities that are involved in certaindata-consuming transactions. Such a change may not necessarily changethe total amount of data that is being consumed; rather, in some cases,this type of change may be motivated by business considerations (e.g.,financial considerations) that are relevant to a particular environment.

B. Illustrative Processes

FIGS. 16-19 show procedures that explain one manner of operation of theenvironment of FIG. 1. Since the principles underlying the operation ofthe environment 100 have already been described in Section A, certainoperations will be addressed in summary fashion in this section.

Starting with FIG. 16, this figure shows a procedure 1600 that presentsan overview of one illustrative manner of operation of the environment100 of FIG. 1. In block 1602, the processing system 106 can receiveactual usage data (i.e., data-related actual usage data) from userdevices operated by respective users. One of the user devices is aparticular user device operated by a particular user. In block 1604, theprocessing system 106 can optionally receive supplemental data which canbe used in the computation of usage information, but does not itselfexpress the consumption of data. For example, the supplemental data mayinclude plan data, user profile data, etc. In block 1606, the processingsystem 106 can optionally receive simulated usage data which reflectsthe simulated usage of applications, and/or energy-related actual usagedata. All of the above data generally constitutes usage data accordingto the terminology used herein.

In block 1608, the processing system 106 generates usage informationbased on any part(s) of the usage data collected in blocks 1602-1606.The usage information may constitute any of personal usage information,expected usage information, projected usage information, comparisonusage information, per-process detailed usage information, etc., asdescribed in Section A.

In block 1610, the environment 100 determines whether a triggering eventhas been received. Illustrative types of triggering events include anexpress request for personal usage information by the particular user,the activation of an application by the particular user, or theactivation of the marketplace system 124 by the particular user. Inblock 1612, in response to the triggering event, the processing system106 presents the appropriate usage information that has been generatedin block 1608, e.g., by presenting personal usage information in somecircumstances and expected usage information in other circumstances(depending on the nature of the triggering event that has beenreceived). FIG. 16 indicates that the usage information is computedprior to the receipt of the triggering event, but the processing system106 can also generate the usage information following the receipt of thetriggering event.

FIG. 17 shows a procedure 1700 for forwarding data-related actual usagedata from the user device 102 to the processing system 106. In block1702, the user device 102 collects the actual usage data from one ormore event sources 304 and stores that data in the temporary store 114.In block 1704, the user device 102 determine whether it is time toupload the actual usage data provided in the temporary store 114. Ifblock 1704 is answered in the affirmative, in block 1706, the userdevice 102 compresses the actual usage data. In block 1708, the userdevice 102 forwards the compressed actual usage data to the processingsystem 106.

FIG. 18 shows a procedure 1800 whereby the device modification module612 (of FIG. 6) can modify the behavior of the user device 102 based onusage information and/or raw usage data (data-related and/orenergy-related). In block 1802, the device modification module 612monitors usage information (or usage data) with respect to a particularapplication. In block 1804, the device modification module 612determines whether the usage exceeds a prescribed threshold or otherwiseconstitutes a triggering event. In block 1806, if block 1604 is answeredin the affirmative, the device modification module 612 modifies thebehavior of the application in any of the ways described in Section A.

Finally, FIG. 19 shows a procedure 1900 by which the processing system106 can generate expected usage information (data-related and/orenergy-related), e.g., when the user visits the marketplace system 124.The processing system 106 performs this task by taking intoconsideration at least one usage-related characteristic of a user.

In block 1902, the processing system 106 receives actual usage data froma group of user devices operated by respective users. The actual usagedata describes actual consumption of data (or other resources) by acandidate application that is run by the user devices. In block 1904,the processing system 106 receives particular user profile dataassociated with the particular user to whom the expected usageinformation is to be presented, together with other user profile dataassociated with the other users (who operate the group of user devices).In block 1906, the processing system 106 computes the expected usageinformation based on the actual usage data, the particular user profiledata, and the other user profile data. For example, assume that the userprofile data reveals that the particular user is a high-consumption datauser. The processing system 106 can form this conclusion by examiningthe manner in which the user interacts with all applications, or justthose applications which are similar to the candidate application inquestion. In one case, the processing system 106 can then form expectedusage information by processing actual usage data obtained from otherhigh-consumption users (within the group of users who have actually usedthe candidate application). More generally, the processing system 106generates the expected usage information for the particular user byapplying the actual usage data from a subset of other users who share atleast one usage-related characteristic in common with the particularuser. For example, two users may be comparable because they both arecategorized as high-consumption data users (in general, or with respectto a certain class of applications). In addition, these two users mayshare the same data plan. In block 1908, the processing system 106 canprovide the expected usage information to the particular user.

C. Representative Computing Functionality

FIG. 20 sets forth illustrative computing functionality 2000 that can beused to implement any aspect of the functions described above. Forexample, the computing functionality 2000 can be used to implement anyaspect of the environment 100 of FIG. 1, e.g., including any user deviceand any aspect of the processing system 106. In one case, the computingfunctionality 2000 may correspond to any type of computing device thatincludes one or more processing devices. In all cases, the electricaldata computing functionality 2000 represents one or more physical andtangible processing mechanisms.

The computing functionality 2000 can include volatile and non-volatilememory, such as RAM 2002 and ROM 2004, as well as one or more processingdevices 2006 (e.g., one or more CPUs, and/or one or more GPUs, etc.).The computing functionality 2000 also optionally includes various mediadevices 2008, such as a hard disk module, an optical disk module, and soforth. The computing functionality 2000 can perform various operationsidentified above when the processing device(s) 2006 executesinstructions that are maintained by memory (e.g., RAM 2002, ROM 2004, orelsewhere).

More generally, instructions and other information can be stored on anycomputer readable medium 2010, including, but not limited to, staticmemory storage devices, magnetic storage devices, optical storagedevices, and so on. The term computer readable medium also encompassesplural storage devices. In all cases, the computer readable medium 2010represents some form of physical and tangible entity.

The computing functionality 2000 also includes an input/output module2012 for receiving various inputs (via input modules 2014), and forproviding various outputs (via output modules). One particular outputmechanism may include a presentation module 2016 and an associatedgraphical user interface (GUI) 2018. The computing functionality 2000can also include one or more network interfaces 2020 for exchanging datawith other devices via one or more communication conduits 2022. One ormore communication buses 2024 communicatively couple the above-describedcomponents together.

The communication conduit(s) 2022 can be implemented in any manner,e.g., by a local area network, a wide area network (e.g., the Internet),etc., or any combination thereof. The communication conduit(s) 2022 caninclude any combination of hardwired links, wireless links, routers,gateway functionality, name servers, etc., governed by any protocol orcombination of protocols.

Alternatively, or in addition, any of the functions described inSections A and B can be performed, at least in part, by one or morehardware logic components. For example, without limitation, illustrativetypes of hardware logic components that can be used includeField-programmable Gate Arrays (FPGAs), Application-specific IntegratedCircuits (ASICs), Application-specific Standard Products (ASSPs),System-on-a-chip systems (SOCs), Complex Programmable Logic Devices(CPLDs), etc.

In closing, functionality described herein can employ various mechanismsto ensure the privacy of user data maintained by the functionality. Forexample, the functionality can allow a user to expressly opt in to (andthen expressly opt out of) the provisions of the functionality. Thefunctionality can also provide suitable security mechanisms to ensurethe privacy of the user data (such as data-sanitizing mechanisms,encryption mechanisms, password-protection mechanisms, etc.).

Further, the description may have described various concepts in thecontext of illustrative challenges or problems. This manner ofexplanation does not constitute an admission that others haveappreciated and/or articulated the challenges or problems in the mannerspecified herein.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

1. A method, implemented by computing functionality, comprising:receiving device resource usage information regarding a particulardevice; receiving candidate resource usage information associated with acandidate application, the candidate resource usage informationdescribing actual and/or estimated consumption of resources by thecandidate application; based on the device resource usage informationand the candidate resource usage information, generating estimatedresource usage information describing an estimate of consumption ofresources if that candidate application were to be executed by theparticular device.
 2. The method of claim 1, further comprisingautomatically modifying the way in which the candidate applicationexecutes on the particular device.
 3. The method of claim 1, wherein theestimated consumption of resources by the candidate application includessimulated resource usage information derived by simulating execution ofthe candidate application.
 4. The method of claim 1, wherein theestimated resource usage represents an amount of energy.
 5. The methodof claim 1, wherein the estimated resource usage represents an amount ofdata.
 6. The method of claim 1, further comprising rendering aninteractive user interface, the interactive user interface presentingone or more selectable views of any one or more of the device resourceusage information, the candidate resource usage information, and theestimated resource usage information.
 7. The method of claim 1, furthercomprising generating the estimated resource usage information withreference to a data plan that governs consumption of data by theparticular device.
 8. The method of claim 1, wherein the candidateapplication is downloadable from an application store.
 9. The method ofclaim 1, further comprising, in response to receipt of the estimatedresource usage information, automatically modifying the behavior of theparticular device.
 10. The method of claim 1, wherein the estimatedresource usage information is generated at the particular device. 11.The method of claim 1, wherein the estimated resource usage informationis generated at a location remote from the particular device.
 12. Themethod of claim 11, further comprising, in response to receipt of theestimated resource usage information, automatically modifying theresources consumed by the candidate application on the particulardevice.
 13. The method of claim 1, wherein the estimated resource usageinformation is generated based further on a user profile associated withthe particular device.
 14. A computer readable storage device forstoring computer readable instructions, the computer readableinstructions providing a usage analysis module when executed by one ormore processing devices, the computer readable instructions comprising:logic configured to receive device resource usage information regardinga particular device; logic configured to receive candidate resourceusage information associated with a candidate application, the candidateresource usage information describing actual and/or estimatedconsumption of resources by the candidate application; and logicconfigured to, based on the device resource usage information and thecandidate resource usage information, generate estimated resource usageinformation describing an estimate of consumption of resources if thatcandidate application were to be executed by the particular device. 15.The computer readable storage device of claim 14, wherein the estimatedconsumption of resources by the candidate application includes simulatedresource usage information derived by simulating execution of thecandidate application.
 16. The computer readable storage device of claim14, further comprising logic configured to automatically modify thebehavior of the particular device.
 17. The computer readable storagedevice of claim 14, further comprising logic configured to automaticallymodify the resources consumed by the candidate application on theparticular device.
 18. A usage analysis module, implemented by computingfunctionality, comprising: logic configured to receive device resourceusage information regarding a particular device; logic configured toreceive candidate resource usage information associated with a candidateapplication, the candidate resource usage information describing actualand/or estimated consumption of resources by the candidate application;logic configured to, based on the device resource usage information andthe candidate resource usage information, generate estimated resourceusage information describing an estimate of consumption of resources ifthat candidate application were to be executed by the particular device;and logic configured to automatically modify the way in which thecandidate application executes on the particular device.
 19. The usageanalysis module of claim 18, further comprising logic configured toautomatically limit the use of one or more features of the candidateapplication on the particular device.
 20. The usage analysis module ofclaim 18, further comprising logic configured to automatically modifythe behavior of the particular device.